Systems and methods for continuously updating and runtime processing of decisioning

ABSTRACT

In some aspects, the techniques described herein relate to a method including: receiving, at an attribute and income platform, demand deposit account information associated with a demand deposit account; receiving, at the attribute and income platform, financial information of a customer associated with the demand deposit account; generating, by the attribute and income platform, a financial profile for the customer; generating, by a customer decisioning platform, a pre-approval of a credit product for the customer, wherein the customer pre-approval is based on the financial profile for the customer; providing, by the event streaming platform, a customer pre-approval topic; publishing the customer pre-approval to the customer pre-approval topic; and subscribing, by one or more processing platforms, to the customer pre-approval topic.

RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional PatentApplication Ser. No. 63/364,942, filed May 18, 2022, and U.S.Provisional Patent Application Ser. No. 63/364,946, filed May 18, 2022,the disclosures of which are hereby incorporated, by reference, in theirentirety.

BACKGROUND

The present disclosure generally relates to systems and methods forproviding continuously updated decisioning.

Recently, organizations that provide credit products have introducedproducts that allow a customer to finance a single transaction with aninstallment loan. Such credit products provide a unique opportunity fororganizations that offer both demand deposit accounts (DDAs) that may beassociated with payment products (e.g., a checking account that has adebit card associated with the account) and credit/financing products.Because DDA's are often used as the source of payment for customertransactions, organizations that offer such accounts have detailedinsight to transactions that may be eligible for transaction installmentloans. But, due to the ever-changing nature of factors such as accountbalances, customers' credit statuses, the rapid and continuous rate atwhich transactions may be made, and the sheer number of transactions(many millions per day) that a providing organization must process, thetechnical challenges in decisioning which transactions are eligible andthen presenting the transactions in a timely manner to a customer aremany and difficult.

To illustrate the technical challenges, consider that customers thatregularly use DDAs and associated payment products (e.g., a debit cardassociated with the DDA) for transactions can generate high volumes oftransactions over relatively short amounts of time. Moreover, when it isconsidered that a providing organization has a high volume of customersthat regularly use DDAs and associated products for transactions (inmany cases, tens of millions of customers), it will be appreciated thatrun-time processing of the total volume of transactions by aninstitution's technology infrastructure for credit product decisioningwould not be practical and would likely not even be possible withoutdedicating an unmanageable and cost-ineffective amount of resources(both technical and human) to such a process. Nevertheless, givencertain credit-based products' applicability to individual transactions(such as short-term installment-based credit products), the ability toefficiently process transaction-level data, process decisioning based ontransaction-level data, and process acceptance of credit products forindividual transactions is needed.

SUMMARY

In some aspects, the techniques described herein relate to a methodincluding: receiving, at an attribute and income platform, demanddeposit account information associated with a demand deposit account;receiving, at the attribute and income platform, financial informationof a customer associated with the demand deposit account; generating, bythe attribute and income platform, a financial profile for the customer;generating, by a customer decisioning platform, a pre-approval of acredit product for the customer, wherein the customer pre-approval isbased on the financial profile for the customer; providing, by an eventstreaming platform, a customer pre-approval topic; publishing thecustomer pre- approval to the customer pre-approval topic; andsubscribing, by one or more processing platforms, to the customerpre-approval topic.

In some aspects, the techniques described herein relate to a method,including: receiving, at the attribute and income platform, a riskscore.

In some aspects, the techniques described herein relate to a method,wherein the risk score is based on the financial profile.

In some aspects, the techniques described herein relate to a method,wherein the customer pre-approval is further based on account stateinformation from a credit account platform.

In some aspects, the techniques described herein relate to a method,including: providing, by the event streaming platform, an account statetopic; streaming, by the credit account platform, the account stateinformation to the account state topic; and subscribing, by the customerdecisioning platform, to the account state topic.

In some aspects, the techniques described herein relate to a method,wherein the one or more processing platforms includes a transactiondecisioning platform.

In some aspects, the techniques described herein relate to a method,wherein the financial profile and the risk score are updated iterativelyon a time interval, and including: determining an eligibility of thecustomer for the customer pre-approval iteratively on the time interval.

In some aspects, the techniques described herein relate to a systemincluding at least one computer including a processor, wherein the atleast one computer is configured to: receive, at an attribute and incomeplatform, demand deposit account information associated with a demanddeposit account; receive, at the attribute and income platform,financial information of a customer associated with the demand depositaccount; generate, by the attribute and income platform, a financialprofile for the customer; generate, by a customer decisioning platform,a pre-approval of a credit product for the customer, wherein thecustomer pre-approval is based on the financial profile for thecustomer; provide, by an event streaming platform, a customerpre-approval topic; publish the customer pre-approval to the customerpre-approval topic; and subscribe, by one or more processing platforms,to the customer pre-approval topic.

In some aspects, the techniques described herein relate to a system,including: receiving, at the attribute and income platform, a riskscore.

In some aspects, the techniques described herein relate to a system,wherein the risk score is based on the financial profile.

In some aspects, the techniques described herein relate to a system,wherein the customer pre-approval is further based on account stateinformation from a credit account platform.

In some aspects, the techniques described herein relate to a system,including: providing, by the event streaming platform, an account statetopic; streaming, by the credit account platform, the account stateinformation to the account state topic; and subscribing, by the customerdecisioning platform, to the account state topic.

In some aspects, the techniques described herein relate to a system,wherein the one or more processing platforms includes a transactiondecisioning platform.

In some aspects, the techniques described herein relate to a system,wherein the financial profile and the risk score are updated iterativelyon a time interval, and including: determining an eligibility of thecustomer for the customer pre-approval iteratively on the time interval.

In some aspects, the techniques described herein relate to anon-transitory computer readable storage medium, including instructionsstored thereon, which instructions, when read and executed by one ormore computer processors, cause the one or more computer processors toperform steps including: receiving, at an attribute and income platform,demand deposit account information associated with a demand depositaccount; receiving, at the attribute and income platform, financialinformation of a customer associated with the demand deposit account;generating, by the attribute and income platform, a financial profilefor the customer; generating, by a customer decisioning platform, apre-approval of a credit product for the customer, wherein the customerpre-approval is based on the financial profile for the customer;providing, by an event streaming platform, a customer pre-approvaltopic; publishing the customer pre-approval to the customer pre-approvaltopic; and subscribing, by one or more processing platforms, to thecustomer pre-approval topic.

In some aspects, the techniques described herein relate to anon-transitory computer readable storage medium, including: receiving,at the attribute and income platform, a risk score.

In some aspects, the techniques described herein relate to anon-transitory computer readable storage medium, wherein the risk scoreis based on the financial profile.

In some aspects, the techniques described herein relate to anon-transitory computer readable storage medium, wherein the customerpre-approval is further based on account state information from a creditaccount platform.

In some aspects, the techniques described herein relate to anon-transitory computer readable storage medium, including: providing,by the event streaming platform, an account state topic; streaming, bythe credit account platform, the account state information to theaccount state topic; and subscribing, by the customer decisioningplatform, to the account state topic.

In some aspects, the techniques described herein relate to anon-transitory computer readable storage medium, wherein the financialprofile and the risk score are updated iteratively on a time interval,and including: determining an eligibility of the customer for thecustomer pre-approval iteratively on the time interval.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a sequence diagram for a decisioning process, in accordancewith aspects.

FIG. 2 is a sequence diagram for transaction decisioning, in accordancewith aspects.

FIG. 3 is a logical flow of runtime processing of a digital channel, inaccordance with aspects.

FIG. 4 is a logical flow for credit decisioning in accordance withaspects.

FIG. 5 is a logical flow for providing eligible transactions to adigital channel, in accordance with aspects.

FIG. 6 is a block diagram of a computing device for implementing certainaspects of the present disclosure.

DETAILED DESCRIPTION

Aspects are directed to systems and methods for providing continuouslyupdated decisioning.

Aspects may provide continuous evaluation and updating of a customer'seligibility for a credit product such that relevant events may beevaluated in real-time, alongside the customer's continuous stream oftransactions such that an eligible transaction list may be constantlymaintained and updated. Moreover, techniques described herein allow aneligible transaction list to be retrieved and list entries to beformatted for display and interaction by the customer in a digitalchannel such as a mobile application or a web page. Conventional systemsthat rely on batch processing of massive or even relatively largeamounts of data at runtime to decision a customer and the customer'stransactions and then format eligible transactions would produceunacceptable latency as a digital channel was launched by the customer.However, using the techniques described herein, customer and transactioneligibility decisioning is continually performed via event streamingtechniques, and further allow for only transactions that have beendecisioned as eligible to undergo specific formatting at runtime whenthe customer authenticates to a digital channel to view transactions.Such pre-differentiation between eligible and non-eligible transactionsenables processing efficiency to return formatted eligibility results ina relatively small amount of time (e.g., 300 ms) that is acceptable tocustomers.

Aspects may include a global credit account platform that can act as asystem of record for aspects described herein. A system of record (SoR),as used herein, refers to a computer system including a storage system(e.g., a relational database) that is an authoritative source for aparticular data element or a piece, or set, of electronic information(e.g., information associated with a credit account of a customer). Acredit account platform may act as a SoR for information related tocredit accounts that are associated with an organization's customers.For instance, a credit account platform may provide data that indicateswhether a customer has or had a credit account with the organization,whether an account is currently opened, closed, or suspended, whetherthe account is in good standing or delinquent, whether charges againstthe account have been written off, etc.

Additionally, a credit account platform can act as the SoR for creditaccounts and can facilitate such actions as housing customer creditaccounts, maintaining account balances and account ledgers, determiningminimum payments on credit accounts, determining payment due dates oncredit accounts, determining late payments on credit accounts,determining late fees on credit accounts, etc.

Aspects may also include a core deposit platform that acts as a SoR fordemand deposit accounts (DDAs) of an organization's customers, includingtransactions and other information associated with a debit card for theDDA. A DDA includes accounts such as checking accounts, savings accountsand other accounts where customers can deposit funds and subsequentlywithdraw the deposited funds on demand or make charges against the fundsin the account with an associated payment card, such as a debit card. Adeposit platform may include a computer system and storage platform thatprocesses deposits (credits) and debits to an associated DDA, retains aledger of funds in a DDA, provides a user interface for managing theDDA, etc.

Aspects may further include a data store, such as a data warehouse or adata lake. The data store, however, may be any suitable data store. Insome aspects, the data store may be an enterprise data warehouse thataggregates data from different sources and makes the data available fordata analysis, data mining, and artificial intelligence (AI) and machinelearning (ML) operations. A data warehouse may include a server thatperforms extract, transform, and load (ETL), or extract, load, andtransform (ELT) operations on data received from multiple sources. TheELT and/or ETL operations may include preparatory operations such ascleaning, standardizing, normalizing, and/or other data operations. Adata warehouse may persist received data to a relational database, anonline analytical processing (OLAP) database, or another appropriatetype of database. The data warehouse may also include a user interfaceand reporting tools and may publish private and/or public applicationprogramming interfaces (APIs) for programmatic submission and retrievalof data stored therein.

Systems may further include an attribute and income platform. Anattribute and income platform may operate as a service that collects,aggregates, and stores customer attributes, including financialinformation associated with a customer, and can store the informationfor use by other platforms and systems. The financial information caninclude information regarding the customer's loans and other financialdealings with the hosting institution (which may be, e.g., a financialinstitution). Types of data that the attribute and income platform maycollect and aggregate include mortgage loan information, auto loaninformation, deposit account information, retirement accountinformation, income information from the customer, etc. An attribute andincome platform may retrieve/receive data from disparate systems of thehosting institution that provides a holistic financial view/profile of acustomer regarding the customer's relationship and accounts with theinstitution. In some aspects, information from outside the institutioncan also be collected at an attribute and income services platform andincorporated into a customer's financial profile. An example of outsideinformation may be credit ratings published by various credit ratingagencies. Credit rating agencies may also provide loan information fromother financial institutions that may be consumed and stored by anattribute and income platform.

Aspects may include a machine learning (ML) engine that includes one ormore servers that execute ML algorithms and/or machine learning modelsand that accept data as an input to a ML algorithm or model and processthe data according to the ML algorithm or model. The output of a MLengine includes “predictions” such as inferences from a ML modelregarding relationships among data points of the input data. A machinelearning algorithm of a ML engine may act as a training function and maytake training data sets as input that train (i.e., fit training data to)a corresponding ML model for modeling of input data and for providingpredictions as output based on the modeled data.

Aspects may include processing of a customer's financial profile (asaggregated by an attribute and income services platform) by an ML enginein order to infer a risk profile based on the financial profile. A riskprofile may measure risk associated with a likelihood that a customerwill default on a credit loan and may include a risk score. A risk scorecan be provided on an appropriate scale (such as a 100-point scale, a10-point scale, etc.). Accordingly, an exemplary risk score may be a 75on a 100-point scale where, as the score increases, the likelihood ofdefault also increases. Risk scores, however, can be configured on anynecessary or desirable scale and with any suitable point value system.

Aspects may additionally include a customer decisioning platform. Acustomer decisioning platform can include logic and functions that takeinformation, including a risk score, and other profile information froma customer, and may output credit decisions associated with thecustomer. The decisions may include product offerings (e.g., creditproduct offerings) for the customer. The customer decisioning platformcan include custom logic, the result of which can manifest in apre-approval of a customer for a credit product offered by the hostinginstitution, or a decision not to offer a credit product to a customer.

Aspects may also include a distributed event streaming platform (e.g.,Apache Kafka®) for handling of associated events in the form of realtime and near-real time streaming data to and from streaming datapipelines and/or streaming applications. Streaming data may becontinuously generated by a data source. An event streaming platform canreceive streaming data from multiple sources and process the datasequentially and incrementally. Event streaming platforms can be used inconjunction with real time and near-real time streaming data pipelinesand streaming applications. For example, an event streaming platform caningest and store streaming data from the data pipeline and provide thedata to an application that process the streaming data. An eventstreaming platform may include partitioned commit logs (each, an orderedsequence of records) to store corresponding streams of records. The logsare divided into partitions, and a subscriber can subscribe to a “topic”that is associated with a partition, and thereby receive all recordsstored at the partition (e.g., as passed to the subscriber in real timeby the platform).

An event streaming platform may expose a producer API that publishes astream of records to a topic, and a consumer API that a consumerapplication can use to subscribe to topics and thereby receive therecord stream associated with that topic. An event streaming platformmay also publish other APIs with necessary or desired functionality.

Aspects may further include a lending innovation platform that is anexperience platform that can create the customer experience required tooffer a credit product to a customer. A lending innovation platform maybuild, or components thereof may be displayed in, a customer-facinginterface.

Aspects may also include a marketing platform. A marketing platform maybe configured to provide a customer with contextual offers based onprevious activity recorded by the hosting institution. Such previousactivity can include transactions, mobile app usage, website usage,third-party data associated with the customer, etc. In the context of acredit product, a marketing platform can provide consumer products andservices for which a customer can employ an offered credit product inorder to pay for the consumer product or service.

In accordance with aspects, approval decisioning for a credit productcan be executed based on a financial profile of a customer and a riskscore of a customer.

In accordance with aspects, an attribute and income platform can receiveDDA information from a core deposit platform. The DDA information caninclude information about a customer's account, including transactions,debit card information, an account balance, etc. The attribute andincome services platform can also receive, from a data store,information that can be aggregated in order to create the customer'sfinancial profile, such as the information noted, above, with respect toa customer's financial profile. The attribute and income servicesplatform can aggregate the DDA information, and the data received fromthe data store that includes all of the customer's financial activityand accounts with the hosting institution, to create a holisticfinancial profile for the customer.

In accordance with aspects, after aggregation, an attribute and incomeplatform may send the customer's financial profile to a ML learningengine, and the machine learning engine can receive the financialprofile and process the data included in the financial profile toproduce a risk score for the customer based on the financial profile. Inaccordance with aspects, exemplary data that may be sent to a ML engineand/or decisioning engine (and that may also be included in a financialprofile) includes whether a customer has an eligible DDA; whether theDDA has a minimum timeframe (e.g., a minimum of 90 days) of regularinflow funding (e.g., regular deposits by an employer, or from anothersource); a minimum average balance of the DDA; a minimum current balanceof the DDA; a minimum account-opened period (e.g., has the account beenopened at least 6 months?); a minimum age of the customer associatedwith the DDA; whether the customer has an eligible payment (i.e., debit)card linked to the DDA; whether the customer is an auto or home ownerand the status of any loans on the customer's auto or home; etc.

After processing profile data from an attribute and income platform, theML engine can then transmit the risk score to the customer decisioningplatform. Likewise, after aggregation, the attribute and income servicesplatform can send the customer's holistic financial profile to thecustomer decisioning platform. The customer decisioning platform mayreceive the customer's financial profile and the risk score associatedwith the profile data and may use the risk score and the financialprofile data in an eligibility decisioning process for issuing creditproducts, such as installment loans for transaction line items on a DDAledger. In some aspects, the customer decisioning platform may receivethe financial profile in parallel with the risk score.

In accordance with aspects, a credit account platform may be a SoR withrespect to credit accounts provided to customers of a providinginstitution. A credit account platform may store credit account datarelated to credit accounts associated with a customer. Credit accountdata may include details and metadata with respect to a parent creditaccount and installment loan accounts that are sub accounts of a parentaccount. A parent credit account may be a parent to one or moreinstallment loan accounts. That is, a parent account may be ahierarchical account at the top of a hierarchy, under which one or moreinstallment loan accounts are issued. A state of a parent credit accountmay affect decisioning as to whether one or more installment loans areissued under the parent account.

In accordance with aspects, one or more installment loan accounts may beissued under a customer's parent credit account. If a customer's parentcredit account is in good standing (i.e., hasn't been disqualified forissuance of additional installment loan instances for any reason) thenone or more installment loan accounts may be generated under the parentaccount. In accordance with aspects, a state of an installment loanaccount issued under a parent credit account may affect the state of theparent credit account.

A credit account platform may publish account details with respect to aparent credit account to a topic provided by an event streamingplatform. An event streaming platform may provide a parent account statetopic for a parent credit account of a customer. A credit accountplatform may push account details of the parent credit account to theparent account state topic. Parent credit account details published tothe topic may include changes in the parent credit account state, suchas whether the account is opened, closed, delinquent, or has beencharged-off (i.e., written off for business and/or accounting purposes).

A credit account platform may also publish account data with respect toa state of an installment loan account of a customer to a topic providedby an event streaming platform. An event streaming platform may providean installment loan account state topic for an installment loan accountof a customer. Installment account details that may be published to acorresponding topic may include whether the account is opened, closed,suspended, delinquent, etc.

In accordance with aspects, a customer decisioning platform maysubscribe to a parent credit account topic and/or an installment loanaccount topic that is published by an event streaming platform and thatcorresponds to a customer parent credit account or a customerinstallment loan account. A customer decisioning platform may use thestreamed account data in a decisioning process for approving ordisqualifying a corresponding customer for one or more installment loansand associated accounts.

A customer decisioning platform may subscribe to a parent account statetopic published by an event streaming platform. A customer decisioningplatform may receive parent credit account data sent to the topic by acredit account platform as a stream of data from an event streamingplatform. Moreover, a customer decisioning platform may subscribe to aninstallment loan account state topic published by an event streamingplatform. A customer decisioning platform may receive installment loanaccount data sent to the topic by a credit account platform as a streamof data from an event streaming platform. A customer decisioningplatform may use the data received from the parent account state topicand the installment loan account state topic as input data indecisioning eligibility of an associated customer for one or moreinstallment loan accounts.

In accordance with aspects, a customer decisioning platform maydetermine eligibility of a customer for an installment loan account andcorresponding installment loan based on a parent account state providedby a credit account platform, one or more installment loan accountstates provided by a credit account platform, a financial profile asaggregated by an attribute and income platform, and a risk scoregenerated by a ML engine and based on a financial profile of a customer.Each of the parent account state, the installment loan account state,the financial profile, and the risk score may be associated with therelevant customer. The customer decisioning platform may determine,based on the customer's aggregated financial profile and the customer'srisk score whether to pre-approve the customer for an installment loanor other credit product that is offered by the providing institution.Moreover, the customer decisioning platform may provide, as part of apre-approval decision for a customer, a total finance amount that may beapplied to transaction installment loan offers and that is also based onthe factors received by the customer decisioning platform.

In some aspects, a credit account platform may provide a total financeamount for a customer based on the credit account platform's retainedglobal credit account data with respect to a customer. In such aspects,a credit account platform may periodically update a total finance amountassociated with a customer and may transmit changes in a customer'stotal finance amount to an event streaming platform with, e.g., a parentaccount state update and/or an installment loan account state update torespective topics provided by an event streaming platform. In suchaspects, a customer decisioning platform may receive the total financeamount from the event streaming platform and may include the totalfinance amount in data published to a customer pre-approval topic asdiscussed in more detail, herein.

In accordance with aspects, a transaction installment loan may includean installment type credit product that allows the customer to pay for apurchase over several time-based installments. The relevant purchase maybe a purchase paid for from a DDA and recorded as a transaction on aledger of the DDA. For instance, an installment loan product may be a4-installment payment product, where the installment payments arescheduled weekly, monthly, or at some other increment. Aninstallment-based credit product is only exemplary, and the techniquesdescribed herein can be used to provision other types of creditproducts.

In accordance with aspects, a total financing amount may be the totalamount of funds that a customer may receive for an offer of one or moreinstallment loans. That is, if a total finance amount is one thousanddollars ($1000), then a customer may be eligible for a number ofinstallment loans that are equal to or less than the total financeamount. For instance, if a customer has been pre-approved and has beenallocated a total finance amount of $1000, then that customer may beeligible for a transaction installment loan on a first transaction thattotaled $500, a second transaction that totaled $300, and a thirdtransaction that totaled $200. If, however, the customer has accepted anoffered loan for each of the transactions mentioned above, then thecustomer may not be eligible for additional transaction installmentloans until an actual financed amount falls back below the customer'stotal finance amount.

In accordance with aspects, once the customer decisioning platform hasdetermined whether to approve or deny a credit product based on, e.g.,the factors mentioned, above, the customer decisioning platform can sendthe decision to a distributed event streaming platform. That is, thecustomer decisioning platform can publish the information to a topicprovided by an event streaming platform. For instance, the customerdecisioning platform may publish a pre-approval for an installment loanaccount to a customer pre-approval topic provided by an event streamingplatform. Moreover, the customer decisioning platform may publish adenial of approval or a disqualification for an installment loan accountto a customer disqualification topic provided by an event streamingplatform. In some aspects, the decisioning engine may publish apre-approval and a disqualification to the same topic for a givencustomer. Other systems and platforms may subscribe to the topic ortopics in order to determine whether a customer is pre-approved for aninstallment loan account and corresponding loan, or whether they aredisqualified or ineligible for such an account and corresponding loan.

In accord with aspects, the process of decisioning an approval or adenial of a credit product for a customer can be ongoing and canincorporate changes in the customer's financial profile and/or changesin a parent or installment loan account state. Changes in the customer'sfinancial profile can result in changes in the customer's risk score,which is based on the customer's financial profile. Other factors thatare incorporated into the customer's holistic financial profile can alsoresult in changes to the decisioning of the customer decisioningplatform. For example, a customer may pay down, or pay off, one or moreother loans that the customer has with the hosting institution, oranother institution (and which is reported to the hosting institutionand incorporated into the customer's financial profile). A customer maypay off an auto loan, a mortgage, etc., which may affect the customer'sability to assume more debt in the form of a credit product offered bythe hosting institution. Conversely, the customer may miss severalpayments, or go into default, with respect to an existing credit loan,and this may cause a denial of further credit accounts by the customerdecisioning platform.

In order to keep decisions made by the customer decisioning platform“evergreen” with profile information, account information, and riskscores that are based on current information, the decisioning processdescribed above can be continually executed. Continual execution can befacilitated through time-based batch processing of the steps describedherein. For instance, a customer profile and a risk score can be updatedevery day, week, month, etc., and a corresponding updated decision canbe published to a distributed event streaming platform for consumption.Moreover, a decisioning engine may receive, in real time or near-realtime, changes in topics (such as parent account state and installmentloan account state) that it subscribes to and may publish a change inapproval status to appropriate topics such that other systems andplatforms that subscribe to the topics can determine a customer'saccount eligibility.

In other aspects, trigger events may be defined that, when detected,trigger a fresh decisioning cycle. For example, a missed payment on anexisting credit account or product may be listened for in a hostinginstitution's various SoRs, and when encountered may start a decisioningcycle in real time. The real-time time decisioning cycle may include allor some of the steps described, above. The real-time decisioning cyclecan result in non-approval of new credit product offerings for acustomer until a later decisioning cycle that indicates a lower risk forthe customer. Likewise, remedial actions (e.g., bringing an existingcredit account current) may also trigger a real-time decisioning cyclethat may result in approval decisioning for other credit products.

FIG. 1 is a sequence diagram for a decisioning process, in accordancewith aspects. FIG. 1 includes credit account platform 110, depositplatform 112, data store 114, attribute and income platform 116, machinelearning (ML) engine 118, customer decisioning platform 120, and eventstreaming platform 122.

In accordance with aspects, at step 150 deposit platform 112 may sendDDA data to attribute and income platform 116. For instance, depositplatform 112 may send DDA information for one or more accounts owned bycustomers of the providing institution that maintain a DDA with theproviding institution. DDA information may include an account balance,line-item transactions from a debit card linked to the account,deposits, withdrawals, an indication of whether the account is overdrawnor has been overdrawn within a given time period, and other accountinformation as is necessary or desired. Deposit platform 112 may sendthe account information in any suitable manner. For instance, theaccount data may be sent as a batch file on a recurring basis (e.g.,hourly, daily, etc.), the account data may be sent via an API toattribute and income platform 116, the account data may be sent as adata stream to attribute and income platform 116, etc.

In accordance with aspects, at step 152 data store 114 may sendfinancial profile data to attribute and income platform 116. Data store114 may be any suitable data store, such as an enterprise-level datawarehouse, a relational database, a data lake, etc. Data store 114 mayreceive data from multiple SoRs maintained by a providing institution.Exemplary SoRs include lending systems that maintain records of variousloans issued by the providing institution to a customer, investmentaccounts and balances held by a customer, payment card accounts (e.g.,such as credit card accounts) including balances and payment records ofa customer, etc. In some aspects, data store 114 may receive data fromsources outside of the providing institution. For instance, financialand debt accounts from other institutions may be received and creditratings from credit agencies may be received via, e.g., external APIgateways. Any data that is available to data store 114 and that may bedesirable for generation of a holistic financial profile of a customermay be collected at data store 114. All data collected at data store 114may include a relational link to a customer of the providinginstitution, so that a financial profile generated from the collecteddata may be associated with a particular customer.

At step 154, attribute and income platform 116 may aggregate the datareceived into a holistic financial profile for the customer. Theholistic financial profile may include data received from depositplatform 112 and from data store 114. As noted, above, a holisticfinancial profile of a customer may include data from various systems.The data may be sent to data store 114 and collected and aggregated byattribute and income platform 116 into a financial profile of acustomer. A financial profile may include DDA information such ascredits, debits, and a balance. A financial profile may further includeloan information associated with an organization's customer, creditinformation of the customer, assets of the customer, the customer'sincome, etc. An aggregated financial profile may include pertinentinformation from various organizational systems (and, in some aspects,from outside systems) for decisioning a credit product.

In accordance with aspects, after aggregation, attribute and incomeplatform 116 may send the customer's financial profile to ML engine 118at step 156, and ML engine 118 may receive the financial profile andprocess the data included in the financial profile to produce a riskscore for the customer based on the financial profile. In accordancewith aspects, exemplary data that may be sent to ML engine 118 (and thatmay also be included in a financial profile) includes whether a customerhas an eligible DDA; whether the DDA has a minimum timeframe (e.g., aminimum of 90 days) of regular inflow funding (e.g., regular deposits byan employer, or from another source); a minimum average balance of theDDA; a minimum current balance of the DDA; a minimum account-openedperiod (e.g., has the account been opened at least 6 months?); a minimumage of the customer associated with the DDA; whether the customer has aneligible payment (i.e., debit) card linked to the DDA; whether thecustomer is an auto or home owner and the status of any loans on thecustomer's auto or home, etc.

After processing profile data from an attribute and income platform, MLengine 118 may then transmit the risk score to customer decisioningplatform 120 at step 158. Likewise, after aggregation, attribute andincome platform 116 may send the customer's holistic financial profileto customer decisioning platform 120 at step 160. Customer decisioningplatform 120 may receive the customer's financial profile and the riskscore associated with the profile data and may use the risk score andthe financial profile data in an eligibility decisioning process forissuing credit products, such as installment loans for transaction lineitems on a DDA ledger. In some aspects, customer decisioning platform120 may receive the financial profile in parallel with the risk score.

In accordance with aspects, at step 162 credit account platform 110 maypublish account details with respect to a parent credit account to atopic provided by event streaming platform 122. Event streaming platform122 may provide a parent account state topic for a parent credit accountof a customer. Credit account platform 110 may push account details ofthe parent credit account to the parent account state topic. Parentcredit account details published to the topic may include changes in theparent credit account state, such as whether the account is opened,closed, delinquent, or has been charged-off (i.e., written of forbusiness and/or tax purposes).

At step 164, credit account platform 110 may further publish accountdata with respect to a state of an installment loan account of acustomer to a topic provided by event streaming platform 122. Eventstreaming platform 122 may provide an installment loan account statetopic for an installment loan account of a customer. Installment accountdetails that may be published to a corresponding topic may includewhether the account is opened, closed, suspended, delinquent, etc.

Customer decisioning platform 120 may subscribe to a parent creditaccount topic and/or an installment loan account topic that is publishedby event streaming platform 122 and that corresponds to a customerparent credit account and a customer installment loan account. Customerdecisioning platform 120 may use the streamed account data in adecisioning process for approving or disqualifying a correspondingcustomer for one or more installment loans and associated accounts.

At step 166, customer decisioning platform 120 may subscribe to a parentaccount state topic published by event streaming platform 122. Customerdecisioning platform 120 may receive parent credit account data sent tothe topic by credit account platform 110 as a stream of data from eventstreaming platform 122. Moreover, at step 168, customer decisioningplatform 120 may subscribe to an installment loan account state topicpublished by event streaming platform 122. Customer decisioning platform120 may receive installment loan account data sent to the topic bycredit account platform 110 as a stream of data from event streamingplatform 122. Customer decisioning platform 120 may use the datareceived from the parent account state topic and the installment loanaccount state topic as input data in decisioning eligibility of anassociated customer for one or more installment loan accounts.

At step 170, customer decisioning platform 120 may publish customerpre-approval events to a topic provided by event streaming platform 122.For instance, the customer decisioning platform may publish apre-approval for an installment loan account to a customer pre-approvaltopic provided by customer decisioning platform 120. Moreover, customerdecisioning platform 120 may publish a denial of approval or adisqualification for an installment loan account to a customerdisqualification topic provided by event streaming platform 122 at step172. In some aspects, the decisioning engine may publish a pre-approvaland a disqualification to the same topic for a given customer. Othersystems and platforms may subscribe to the topic or topics in order todetermine whether a customer is pre-approved for an installment loanaccount and corresponding loan, or whether they are disqualified orineligible for such an account and corresponding loan.

In accordance with aspects, a data store may subscribe to a customerpre-approval topic and/or a customer disqualification topic provide byan event streaming platform an d may ingest, and store data streamedfrom the topic(s) as associated with a particular customer. Moreover, adata store may provide the current approval or disqualification state asa part of the associated customer's financial profile that is sent to acustomer decisioning platform and a ML engine in the process describedabove. This allows a current approval or disqualification state to bepart of a customer's financial profile and allows a customer's currentapproval or disqualification state to be considered as a factor in thegeneration of a risk score by an ML engine and the ultimate decisioningof a customer's pre-approval state by a customer decisioning platform.

Customer pre-approval or disqualification may be streamed to and from anevent streaming platform with a customer identifier, and a data storemay store the received pre-approval or disqualification as associatedwith the relevant customer. The data store may store all data associatedwith a particular customer using the customer identifier as a key. Thedata store may use the key when extracting data associated with acustomer for transmission to an attribute and income platform.

In accordance with aspects, individual transactions made using acustomer's DDA can be evaluated by a providing institution's processingsystems to decision whether an individual transaction is eligible to bethe basis of a credit offering such as an installment loan. Transactionmemos can be streamed in real time to a distributed event streamingplatform, and a transaction decisioning platform can be configured toreceive the transaction memos and decision a credit product offering.

In accordance with aspects, a customer can be alerted to a creditproduct offering through a digital channel such as a mobile application,a website, where the mobile application or the website or anothersuitable digital channel displays, via a user interface, a list oftransactions associated with a DDA of the user. For example, the listentry describing a particular transaction that is eligible for a creditproduct can be displayed in a different color, a different font, abolded or italicized font, etc. Moreover, list entries can behyperlinked or deep linked, and a link can lead a customer to an actionprovided through the digital channel where the customer can accept thecredit product offering.

When a customer uses a DDA and an associated payment product for atransaction, two types of transaction notifications can be generated andrecorded by the processing institution. The first type is a transactionmemo. A transaction memo alerts the customer (e.g., through a digitalchannel, such as a mobile app of the hosting financial institution) thatthe transaction has been initiated and approved. And, while thetransaction memo is generally posted within a very short timeframe ofthe actual transaction (often in real time or near-real time), thetransaction memo does not reflect settlement of the transaction by thefinancial institution and the merchant with which the transaction wasentered into by the customer. Rather, a “hard-posted” transaction lineitem represents the settled transaction with the merchant.

Most memo transactions will eventually be converted into hard-postedtransactions after settlement has occurred. Completion of settlement,however, can take several days. Thus, when a financial institutionwishes to offer the transacting customer a credit product, it can beadvantageous to base the offering on the memo transaction, since anoffer based on a memo transaction will be available nearly immediatelyto the customer. Aspects described herein, however, can be applied toboth transaction memos and hard-posted transactions, and aspects cantransfer an association of a credit product, such as a transactioninstallment loan, from a memo transaction to a hard-posted transactiononce the hard-posted transaction is posted to a customer's account on adeposit platform.

In accordance with aspects, a core deposit platform can streamtransaction data, in real time, to a distributed event streamingplatform. In some aspects, the transaction data can be real timetransaction memos generated at the point of transactions. In otheraspects, the transaction data can be transactions that have been settledand are being posted as settled to a DDA (i.e., a hard-postedtransaction). A transaction decisioning platform can subscribe toreceive the stream of transaction information from an event streamingplatform.

The transaction decisioning platform can process a stream oftransactions from a deposit platform through pre-eligibility algorithms,the output of which is a decision as to whether the transaction iseligible for application of a transaction installment loan creditproduct. The pre-eligibility algorithms can include customerpre-approval decisioning outcomes for a customer associated with aparticular DDA, as discussed herein. The transaction decisioningplatform may execute as a streaming application that processes thetransactions as they are received from a distributed event streamingplatform and that provides pre-approval decisioning of each transactionreceived. Any transactions that are decisioned as eligible by thepre-eligibility algorithms can be flagged and added to a list (i.e., aneligible transaction list). In this way, a list of eligible transactionscan be processed (e.g., at runtime) as the customer authenticates to adigital channel provided by the hosting institution.

In accordance with aspects, a deposit platform may stream transactionsprocessed against a customer DDA that are received at the depositplatform. A deposit platform may hold account data for a DDA of acustomer, and the account data may include such information as anaccount balance, an account ledger (including debits and credits, a listof transactions for which account funds are used as payment (e.g., via apayment card such as a debit card associated with the account), etc. Thedeposit platform may publish payment transactions to a topic provided byan event streaming platform. For instance, a deposit platform maypublish each memo transaction associated with a DDA to a memotransaction topic. As transactions (e.g., memo transactions) associatedwith a DDA are received by the deposit platform, the deposit platformmay stream each transaction to the event streaming platform via thecorresponding topic.

In accordance with aspects, a deposit platform may publish alltransactions (e.g., all memo transactions) to a provided topic. Thetransactions streamed to a topic may each have identifiers thatspecifies a corresponding DDA that the transaction was made against anda payment product (e.g., a debit card) that was used for thetransaction. In this way, streamed transactions can be associated withthe correct account and payment product by, e.g., a transactiondecisioning platform. Moreover, a credit account platform may store acustomer profile which maps customer profiles to corresponding DDAs andpayment products that are owned by a customer associated with thecustomer profile. Account state information streamed to a correspondingtopic provided by an event streaming platform may include thesemappings. Accordingly, platforms such as a customer decisioning platformand a transaction decisioning platform may determine a DDA, a paymentproduct and a customer profile that are associated with a particulartransaction, or any necessary or desirable interrelations among thesedata points. Platforms may also determine transaction eligibility basedon customer, account, and transaction level eligibility criteria, asdiscussed further, herein.

In accordance with aspects, a transaction decisioning platform maysubscribe to a transaction topic, such as a memo transaction topic, andmay receive all incoming topics associated with a customer and thecustomer's corresponding DDA. For each received transaction, atransaction decisioning engine may apply a suite of transactioneligibility rules to determine if the received transaction is eligiblefor a transaction installment loan.

Transaction eligibility rules may include eligibility checks, some orall of which must be met in order for a particular transaction toqualify for eligibility of a credit product. Moreover, some rules maydisqualify a transaction. For instance, a transaction may need to bemore than a minimum amount and less than a maximum amount. Certaintransaction types may not be eligible for an installment loan offer(i.e., a rule may be a list of excluded transaction types that are noteligible, and if a transaction type identifier matches an identifier onthe list, the transaction is not eligible). Moreover, a timestamp of atransaction may need to be within a defined time of the eligibilitycheck. The transaction may be disqualified if there is a dispute tagindicating that the customer has disputed the transaction. Othernecessary or desired rules may be evaluated for each transaction todetermine eligibility.

A transaction decisioning platform may further consider an associatedcustomer's eligibility for a transaction installment loan, and theassociated customer's total finance amount. A transaction decisioningengine may subscribe to a customer pre-approval topic and/or a customerdisqualification topic provided by an event streaming platform and mayuse data streamed from the topics, as described herein, in approving ordenying a transaction installment loan for a transaction. For instance,a transaction decisioning platform may check, before issuing an approvalof a transaction installment loan for a transaction, that a customer iseligible for a transaction approval loan and that a customer hassufficient funds, based on the customer's total finance amount, thathave not been applied to one or more other transaction installmentloans. Because eligibility and a total finance amount may change anytime an update is received from the customer pre-approval or thecustomer disqualification topics provided by the event streamingplatform, the transaction decisioning engine may check these parameterseach time a transaction is otherwise approved for a transactioninstallment.

In accordance with aspects, if a transaction is approved for atransaction installment loan, and a customer that is associated with thetransaction is preapproved for a transaction installment loan and hassufficient funds with respect to a total finance amount, the transactionmay be approved for a transaction installment loan. A transactiondecisioning platform may publish an approval of a transactioninstallment loan for a transaction to a topic provided by an eventstreaming platform. The transaction decisioning platform may streamapprovals for eligible transaction to the provided topic, and othersystems may subscribe to the topic to receive and further processrelevant transactions a transaction installment loan processing. In thecase that an eligible transaction becomes stale (e.g., the transactioninstallment loan is not accepted in a predefined amount of time), thetransaction decisioning engine may invalidate the approved transactioninstallment loan for the relevant transaction. Invalidations ofapprovals may also be streamed to an offer invalidation topic providedby an event streaming platform and other systems and platforms mayfurther subscribe to the invalidation topic to determine when atransaction installment loan offer has been invalidated/rescinded by thetransaction decisioning platform.

FIG. 2 is a sequence diagram for transaction decisioning, in accordancewith aspects. FIG. 2 includes deposit platform 212, event streamingplatform 222, and transaction decisioning platform 224. At step 250,deposit platform 212 may publish transactions (e.g., each memotransaction) that are posted to a DDA associated with deposit platform212 to a DDA transaction topic provided by event streaming platform 222.Each publication to the DDA transaction topic may include varioustransaction details whose values may be used to determine whether thetransaction is eligible for a transaction installment loan.

At step 270, transaction decisioning platform 224 may subscribe to acustomer pre-approval topic provided by event streaming platform 222.The customer pre-approval topic may include an indication whether arelevant customer (a customer associated with a particular topic) isapproved for any transaction installment loan offer. The customerpre-approval topic may include other data as further discussed herein.Moreover, transaction decisioning platform 224 may subscribe to thecustomer disqualification topic provided by event streaming platform 222at step 272. The customer disqualification topic may stream anydisqualification or ineligibility of a customer to transactiondecisioning platform 224. At step 274, transaction decisioning platformmay subscribe to the DDA transaction topic that is provided by eventstreaming platform 222 and receive the published stream of DDAtransaction from deposit platform 212. At step 276, transactiondecisioning platform 224 may also subscribe to a total finance amounttopic provided by event streaming platform 222. The total finance amounttopic may stream updates to a customer's total finance amount based oncriteria discussed, above. As discussed above, a credit account platformmay publish updates for a customer's total finance amount to the totalfinance amount topic provided by event streaming platform 222. In otheraspects, a customer's total finance amount may be provided via thecustomer pre-approval topic.

In accordance with aspects, for each received transaction, transactiondecisioning platform 224 may apply transaction eligibility rules at step252. If, after application of transaction eligibility rules, atransaction is determined to be eligible, transaction decisioningplatform 224 may apply customer eligibility rules at step 254 todetermine that the relevant customer is still eligible to receive atransaction installment loan and that the relevant customer still hassufficient funds with respect to the customer's total finance amount. Iftransaction decisioning platform 224 determines that the customer isstill eligible and has sufficient credit funds, transaction decisioningplatform 224 may issue an eligible transaction notification and publishthe eligible transaction notification to an eligible transaction topicat step 278. Various other platforms and system may subscribe to theeligible transaction topic to determine transactions for which atransaction installment loan offer may be made.

The steps described above, may be performed in any necessary ordesirable order. For instance, a transaction decisioning engine mayfirst check that a corresponding customer is eligible at large for atransaction installment loan, and then check incoming transactions foreligibility. In some aspects, a transaction decision engine may includea binary eligibility flag for a corresponding customer, The flag's valuemay be switched based on a last received update from either a customerpre-approval topic or a customer disqualification topic. That is, if alast received update is from a customer pre-approval topic (indicatingthat a customer is currently eligible for a transaction installmentloan) then the eligibility flag may be set to an eligible value. If,however, a last received update is from a customer disqualificationtopic (indicating that a customer is currently ineligible for atransaction installment loan, then the eligibility flag may be set to anineligible value. In this way, a transaction decisioning engine maysimply and efficiently inspect a binary value to determine customereligibility.

If a transaction that was previously published as an eligibletransaction needs to be invalidated for any reason (e.g., if transactiondecisioning platform 224 receives an update indicating that the relevantcustomer was disqualified for a transaction installment loan, if anupdate to the relevant customer's total finance amount indicates atransaction is no longer eligible, if an eligible transaction was postedlonger than a time limit applied to a loan offer, etc.), thentransaction decisioning platform 224 may publish an invalidation for therelevant transaction via an invalidated transaction topic at step 280.

In accordance with aspects, when a transaction installment loan offer ismade and excepted based on a memo transaction, and the memo transactionis later updated with a hard-posted transaction (indicating settlement),any corresponding transaction installment may be re-associated with theupdated, hard-posted transaction in appropriate systems, and processingand servicing of loan details may proceed with the loan in relation tothe recorded, hard-posted transaction.

In accordance with aspects, in order to optimize the display oftransactions that are eligible for credit product offerings, onlytransactions that have been decisioned as eligible undergo alertprocessing at runtime when the customer authenticates to the digitalchannel to view transactions. This differentiation between eligible andnon-eligible transactions enables processing efficiency to returnalerting results in a relatively small amount of time (e.g., 300 ms)that is acceptable to customers.

In accordance with aspects, when a customer authenticates to a digitalchannel (such as a webpage published by a webserver of a providinginstitution, or an application (e.g., a mobile application) provided bya providing institution), the digital channel may execute a method(e.g., a getEligibleTxnList method), and the method may retrieve acurrent list of transactions that are eligible for payment deferralthrough a credit product such as a transaction installment loan (i.e.,an eligible transaction). The method may return a list of eligibletransactions.

In accordance with aspects, an eligible transaction list may be builtfrom an eligible transaction topic that is streamed to a list buildingengine. For instance, a list building engine may subscribe to aneligible transaction topic and an invalidated transaction topic and mayreceive streaming data from the respective topics. An eligibletransaction list may be continually updated with data received from aneligible transaction topic and an invalidated transaction topic. Thelist building engine may amend the list as transactions are updated. Thelist building engine may add transactions received from an eligibletransaction topic to an eligible transaction list and may deletetransactions received from an invalidated transaction topic form aneligible transaction list.

A digital channel may request and process an eligible transaction listat runtime. That is, as the digital channel is launched (e.g., thelaunching of a mobile application or retrieving of a webpage from a webserver, where either may be after authentication), it may request aneligible transaction list and may parse the list. The digital channelmay build a list of all transactions made by an associated customer(e.g., either hard-posted or memo transactions) as is conventionallydisplayed with respect to a DDA ledger-type interface. This conventionallist of historic transactions may be referred to as a transactionhistory list.

The digital interface may receive the eligible transaction list, whichmay include transaction identifiers for each eligible transaction. Thedigital channel may parse the list and match eligible transactions froman eligible transaction list to corresponding transactions in atransaction history list built by a digital channel. The digital channelmay format a transaction line item in a transaction history list as aneligible transaction. Eligible transaction formatting may take one ormore of several different forms. For instance, an eligible transactionmay be formatted in a different font, a different font color, may beformatted as a hyper link or a deep link, may be formatted withadditional information that is not present in line items displayed forineligible transactions, etc. Any suitable formatting that sets thetransaction line item for an eligible transaction visually apart from anineligible transaction line item in a transaction history list may beapplied. Moreover, any functional formatting (e.g., hyper or deep linkformatting) that is necessary or desirable for facilitating acceptanceof a credit product that may be applied to an eligible transaction mayadditionally or alternatively be applied.

In accordance with aspects, formatting and other processing of aneligible transaction list may be applied at runtime of the digitalchannel within acceptable performance bounds, because an eligibletransaction list will be prepopulated and will be relativelylight-weight and efficient to retrieve. As noted above, the techniquesdescribed herein facilitate formatting of updated eligible transactionsin a transaction history list at runtime of the displaying digitalchannel because the list is pre-populated and continually updated priorto its retrieval by a digital channel. Accordingly, only relatively fewsteps must be executed by a digital channel in order to display acurrent list of eligible transactions, and these steps may be processedwith relatively low latency that will be acceptable to a customer duringthe launch of a digital channel.

In accordance with aspects, once eligible transactions are appropriatelyformatted and displayed in a transaction history list, a customer mayinteract with the eligible transactions in order to accept an offeredcredit product, such as a transaction installment loan, and apply theproduct to the eligible transaction. For instance, in the case where aneligible transaction is formatted as a hyper link or a deep link, acustomer may activate the link and the link may launch a differentinterface (in the same or a different digital channel) and the differentinterface may facilitate interaction by the customer that applies theoffered credit product to the corresponding eligible transaction. Uponacceptance of an offered credit product, a digital channel may transmitassociated communications to related processing components. Forinstance, a digital channel may update a credit account platform withthe amount of credit supplied by the offered and accepted creditproduct. That is, if an accepted credit product was applied to a $150transaction, a digital channel may send a notification to a creditaccount platform with the financed amount (i.e., $150 in this example),and the credit account platform may update the corresponding customer'stotal finance amount by reducing the total finance amount by $150. Thisis turn may cause many other updates to be performed as noted, herein.

For instance, if an update to a total finance amount results in thecustomer being at, close to, or over the customer's generated totalfinance amount, this may prompt a credit account platform to send anupdate to a customer decisioning platform and/or a transactiondecisioning platform. In turn, such an update may cause a customerdecisioning platform to publish a customer disqualification event and/ora transaction decisioning platform to publish invalidations for alleligible transactions on an eligible transaction list (so that nofurther credit is offered to the customer above the customer's totalfinance amount). In this way, the acceptance of an offered creditproduct is included in the ongoing process of a customer's creditworthiness along with the other factors described in more detail,herein.

FIG. 3 is a logical flow of runtime processing of a digital channel, inaccordance with aspects.

Step 310 includes requesting, by a digital channel, an eligibletransaction list from a list building engine and receiving the eligibletransaction list form the list building engine. The request may be inthe form of a method, such as an API method exposed by an API gateway ofthe list building engine. The eligible transaction list may be receivedas a return parameter of the called method. It may be in the form of adelineated file, an array object, or any other necessary or desired dataformat.

Step 320 includes matching a transaction from the eligible transactionlists with a transaction included in a transaction history list. Thetransaction history list may be built by the digital channel from a listof transactions made by the customer against an associated DDA. It mayinclude all transactions made against the associated DDA, as may beavailable in a conventional interface for displaying transactionsassociated with a DDA.

Step 330 includes formatting a matched transaction line item as aneligible line item for display in the historical transaction listdisplayed by the digital channel. The formatting may include visualand/or functional formatting that sets the eligible transaction apartfrom ineligible transactions in the transaction history list and/ormakes the line item interactive (e.g., formatting as a hyper or deeplink).

Step 340 includes receiving an activation of an interactive and eligibletransaction line item in the transition history list. An activation mayinclude, e.g., a user “clicking” on or, in the case of a touch interfaceof an electronic device executing the digital channel, touching theformatted transaction line item.

Step 350 includes transmitting, by the digital channel, a communicationto corresponding systems for executing techniques, as described herein.For instance, as discussed above, a digital channel may transmit anacceptance of an offered credit product by a customer and/or an amountof an accepted credit product to a credit account platform or otherplatforms or processing engines.

Other transmissions from a digital channel may include a message to adeposit platform to credit a DDA associated with the transaction forwhich a credit product was accepted for the financed amount. This mayalso initiate processing that deducts payment amounts from theassociated DDA according to the terms of the credit product and updatesrelated systems with updated total finance amounts, as discussed in moredetail, herein.

FIG. 4 is a logical flow for credit decisioning in accordance withaspects.

Step 410 includes receiving, at an attribute and income platform, demanddeposit account information associated with a demand deposit account.

Step 420 includes receiving, at the attribute and income platform,financial information of a customer associated with the demand depositaccount.

Step 430 includes generating, by the attribute and income platform, afinancial profile for the customer.

Step 440 includes generating, by a customer decisioning platform, apre-approval of a credit product for the customer, wherein the customerpre-approval is based on the financial profile for the customer.

Step 450 includes providing, by the event streaming platform, a customerpre-approval topic.

Step 460 includes publishing the customer pre-approval to the customerpre-approval topic.

Step 470 includes subscribing, by one or more processing platforms, tothe customer pre-approval topic.

FIG. 5 is a logical flow for providing eligible transactions to adigital channel, in accordance with aspects.

Step 510 includes receiving, at a transaction decisioning platform, acustomer pre-approval notification.

Step 520 includes receiving, at the transaction decisioning platform, astream of transactions, wherein the transactions are associated with ademand deposit account and the demand deposit account is associated witha customer.

Step 530 includes receiving, at the transaction decisioning platform, atotal finance amount for the customer.

Step 540 includes applying a transaction eligibility rule to eachtransaction in the stream of transactions.

Step 550 includes determining, based on application of the transactioneligibility rules, that one of the transactions from the stream oftransactions is eligible for a credit product.

Step 560 includes determining, based on a customer eligibility variable,that the customer is eligible for the credit product.

Step 570 includes including the one of the transactions from the streamof transactions on an eligible transaction list.

FIG. 6 is a block diagram of a computing device for implementing certainaspects of the present disclosure. FIG. 6 depicts exemplary computingdevice 600. Computing device 600 may represent hardware that executesthe logic that drives the various system components described herein.For example, system components such as a credit account platform, adeposit platform, an attribute and income platform, a ML engine, acustomer decisioning platform, an event streaming platform, atransaction decisioning platform, various database engines and databaseservers, and other computer applications and logic may include, and/orexecute on, components and configurations like, or similar to, computingdevice 600.

Computing device 600 includes a processor 603 coupled to a memory 606.Memory 606 may include volatile memory and/or persistent memory. Theprocessor 603 executes computer-executable program code stored in memory606, such as software programs 615. Software programs 615 may includeone or more of the logical steps disclosed herein as a programmaticinstruction, which can be executed by processor 603. Memory 606 may alsoinclude data repository 605, which may be nonvolatile memory for datapersistence. The processor 603 and the memory 606 may be coupled by abus 609. In some examples, the bus 609 may also be coupled to one ormore network interface connectors 617, such as wired network interface619, and/or wireless network interface 621. Computing device 600 mayalso have user interface components, such as a screen for displayinggraphical user interfaces and receiving input from the user, a mouse, akeyboard and/or other input/output components (not shown).

The various processing steps, logical steps, and/or data flows depictedin the figures and described in greater detail herein may beaccomplished using some or all of the system components also describedherein. In some implementations, the described logical steps may beperformed in different sequences and various steps may be omitted.Additional steps may be performed along with some, or all of the stepsshown in the depicted logical flow diagrams. Some steps may be performedsimultaneously. Accordingly, the logical flows illustrated in thefigures and described in greater detail herein are meant to be exemplaryand, as such, should not be viewed as limiting. These logical flows maybe implemented in the form of executable instructions stored on amachine- readable storage medium and executed by a processor and/or inthe form of statically or dynamically programmed electronic circuitry.

The system of the invention or portions of the system of the inventionmay be in the form of a “processing machine” a “computing device,” an“electronic device,” a “mobile device,” etc. These may be a computer, acomputer server, a host machine, etc. As used herein, the term“processing machine,” “computing device, “electronic device,” or thelike is to be understood to include at least one processor that uses atleast one memory. The at least one memory stores a set of instructions.The instructions may be either permanently or temporarily stored in thememory or memories of the processing machine. The processor executes theinstructions that are stored in the memory or memories in order toprocess data. The set of instructions may include various instructionsthat perform a particular step, steps, task, or tasks, such as thosesteps/tasks described above. Such a set of instructions for performing aparticular task may be characterized herein as an application, computerapplication, program, software program, or simply software. In oneaspect, the processing machine may be or include a specializedprocessor.

As noted above, the processing machine executes the instructions thatare stored in the memory or memories to process data. This processing ofdata may be in response to commands by a user or users of the processingmachine, in response to previous processing, in response to a request byanother processing machine and/or any other input, for example. Theprocessing machine used to implement the invention may utilize asuitable operating system, and instructions may come directly orindirectly from the operating system.

The processing machine used to implement the invention may be ageneral-purpose computer. However, the processing machine describedabove may also utilize any of a wide variety of other technologiesincluding a special purpose computer, a computer system including, forexample, a microcomputer, mini-computer or mainframe, a programmedmicroprocessor, a micro-controller, a peripheral integrated circuitelement, a CSIC (Customer Specific Integrated Circuit) or ASIC(Application Specific Integrated Circuit) or other integrated circuit, alogic circuit, a digital signal processor, a programmable logic devicesuch as a FPGA, PLD, PLA or PAL, or any other device or arrangement ofdevices that is capable of implementing the steps of the processes ofthe invention.

It is appreciated that in order to practice the method of the inventionas described above, it is not necessary that the processors and/or thememories of the processing machine be physically located in the samegeographical place. That is, each of the processors and the memoriesused by the processing machine may be located in geographically distinctlocations and connected so as to communicate in any suitable manner.Additionally, it is appreciated that each of the processor and/or thememory may be composed of different physical pieces of equipment.Accordingly, it is not necessary that the processor be one single pieceof equipment in one location and that the memory be another single pieceof equipment in another location. That is, it is contemplated that theprocessor may be two pieces of equipment in two different physicallocations. The two distinct pieces of equipment may be connected in anysuitable manner. Additionally, the memory may include two or moreportions of memory in two or more physical locations.

To explain further, processing, as described above, is performed byvarious components and various memories. However, it is appreciated thatthe processing performed by two distinct components as described abovemay, in accordance with a further aspect of the invention, be performedby a single component. Further, the processing performed by one distinctcomponent as described above may be performed by two distinctcomponents. In a similar manner, the memory storage performed by twodistinct memory portions as described above may, in accordance with afurther aspect of the invention, be performed by a single memoryportion. Further, the memory storage performed by one distinct memoryportion as described above may be performed by two memory portions.

Further, various technologies may be used to provide communicationbetween the various processors and/or memories, as well as to allow theprocessors and/or the memories of the invention to communicate with anyother entity, i.e., so as to obtain further instructions or to accessand use remote memory stores, for example. Such technologies used toprovide such communication might include a network, the Internet,Intranet, Extranet, LAN, an Ethernet, wireless communication via celltower or satellite, or any client server system that providescommunication, for example. Such communications technologies may use anysuitable protocol such as TCP/IP, UDP, or OSI, for example.

As described above, a set of instructions may be used in the processingof the invention. The set of instructions may be in the form of aprogram or software. The software may be in the form of system softwareor application software, for example. The software might also be in theform of a collection of separate programs, a program module within alarger program, or a portion of a program module, for example. Thesoftware used might also include modular programming in the form ofobject-oriented programming. The software tells the processing machinewhat to do with the data being processed.

Further, it is appreciated that the instructions or set of instructionsused in the implementation and operation of the invention may be in asuitable form such that the processing machine may read theinstructions. For example, the instructions that form a program may bein the form of a suitable programming language, which is converted tomachine language or object code to allow the processor or processors toread the instructions. That is, written lines of programming code orsource code, in a particular programming language, are converted tomachine language using a compiler, assembler or interpreter. The machinelanguage is binary coded machine instructions that are specific to aparticular type of processing machine, i.e., to a particular type ofcomputer, for example. The computer understands the machine language.

Any suitable programming language may be used in accordance with thevarious aspects of the invention. Illustratively, the programminglanguage used may include assembly language, Ada, APL, Basic, C, C++,COBOL, dBase, Forth, Fortran, Java, Modula-2, Pascal, Prolog, REXX,Visual Basic, and/or JavaScript, for example. Further, it is notnecessary that a single type of instruction or single programminglanguage be utilized in conjunction with the operation of the system andmethod of the invention. Rather, any number of different programminglanguages may be utilized as is necessary and/or desirable.

Also, the instructions and/or data used in the practice of the inventionmay utilize any compression or encryption technique or algorithm, as maybe desired. An encryption module might be used to encrypt data. Further,files or other data may be decrypted using a suitable decryption module,for example.

As described above, the invention may illustratively be embodied in theform of a processing machine, including a computer or computer system,for example, that includes at least one memory. It is to be appreciatedthat the set of instructions, i.e., the software for example, thatenables the computer operating system to perform the operationsdescribed above may be contained on any of a wide variety of media ormedium, as desired. Further, the data that is processed by the set ofinstructions might also be contained on any of a wide variety of mediaor medium. That is, the particular medium, i.e., the memory in theprocessing machine, utilized to hold the set of instructions and/or thedata used in the invention may take on any of a variety of physicalforms or transmissions, for example. Illustratively, the medium may bein the form of a compact disk, a DVD, an integrated circuit, a harddisk, a floppy disk, an optical disk, a magnetic tape, a RAM, a ROM, aPROM, an EPROM, a wire, a cable, a fiber, a communications channel, asatellite transmission, a memory card, a SIM card, or other remotetransmission, as well as any other medium or source of data that may beread by a processor.

Further, the memory or memories used in the processing machine thatimplements the invention may be in any of a wide variety of forms toallow the memory to hold instructions, data, or other information, as isdesired. Thus, the memory might be in the form of a database to holddata. The database might use any desired arrangement of files such as aflat file arrangement or a relational database arrangement, for example.

In the system and method of the invention, a variety of “userinterfaces” may be utilized to allow a user to interface with theprocessing machine or machines that are used to implement the invention.As used herein, a user interface includes any hardware, software, orcombination of hardware and software used by the processing machine thatallows a user to interact with the processing machine. A user interfacemay be in the form of a dialogue screen for example. A user interfacemay also include any of a mouse, touch screen, keyboard, keypad, voicereader, voice recognizer, dialogue screen, menu box, list, checkbox,toggle switch, a pushbutton or any other device that allows a user toreceive information regarding the operation of the processing machine asit processes a set of instructions and/or provides the processingmachine with information. Accordingly, the user interface is any devicethat provides communication between a user and a processing machine. Theinformation provided by the user to the processing machine through theuser interface may be in the form of a command, a selection of data, orsome other input, for example.

As discussed above, a user interface is utilized by the processingmachine that performs a set of instructions such that the processingmachine processes data for a user. The user interface is typically usedby the processing machine for interacting with a user either to conveyinformation or receive information from the user. However, it should beappreciated that in accordance with some aspects of the system andmethod of the invention, it is not necessary that a human user actuallyinteract with a user interface used by the processing machine of theinvention. Rather, it is also contemplated that the user interface ofthe invention might interact, i.e., convey and receive information, withanother processing machine, rather than a human user. Accordingly, theother processing machine might be characterized as a user. Further, itis contemplated that a user interface utilized in the system and methodof the invention may interact partially with another processing machineor processing machines, while also interacting partially with a humanuser.

It will be readily understood by those persons skilled in the art thatthe present invention is susceptible to broad utility and application.Many aspects and adaptations of the present invention other than thoseherein described, as well as many variations, modifications, andequivalent arrangements, will be apparent from or reasonably suggestedby the present invention and foregoing description thereof, withoutdeparting from the substance or scope of the invention.

Accordingly, while the present invention has been described here indetail in relation to its exemplary aspects, it is to be understood thatthis disclosure is only illustrative and exemplary of the presentinvention and is made to provide an enabling disclosure of theinvention. Accordingly, the foregoing disclosure is not intended to beconstrued or to limit the present invention or otherwise to exclude anyother such aspects, adaptations, variations, modifications, orequivalent arrangements.

1. A method comprising: receiving, at an attribute and income platform,demand deposit account information associated with a demand depositaccount; receiving, at the attribute and income platform, financialinformation of a customer associated with the demand deposit account;generating, by the attribute and income platform, a financial profilefor the customer; generating, by a customer decisioning platform, acustomer pre-approval of a credit product for the customer, wherein thecustomer pre-approval is based on the financial profile for thecustomer; providing, by an event streaming platform, a customerpre-approval topic; publishing the customer pre-approval to the customerpre-approval topic; and subscribing, by one or more processingplatforms, to the customer pre-approval topic.
 2. The method of claim 1,comprising: receiving, at the attribute and income platform, a riskscore.
 3. The method of claim 2, wherein the risk score is based on thefinancial profile.
 4. The method of claim 1, wherein the customerpre-approval is further based on account state information from a creditaccount platform.
 5. The method of claim 4, comprising: providing, bythe event streaming platform, an account state topic; streaming, by thecredit account platform, the account state information to the accountstate topic; and subscribing, by the customer decisioning platform, tothe account state topic.
 6. The method of claim 1, wherein the one ormore processing platforms includes a transaction decisioning platform.7. The method of claim 3, wherein the financial profile and the riskscore are updated iteratively on a time interval, and comprising:determining an eligibility of the customer for the customer pre-approvaliteratively on the time interval.
 8. A system comprising at least onecomputer including a processor, wherein the at least one computer isconfigured to: receive, at an attribute and income platform, demanddeposit account information associated with a demand deposit account;receive, at the attribute and income platform, financial information ofa customer associated with the demand deposit account; generate, by theattribute and income platform, a financial profile for the customer;generate, by a customer decisioning platform, a customer pre-approval ofa credit product for the customer, wherein the customer pre-approval isbased on the financial profile for the customer; provide, by an eventstreaming platform, a customer pre-approval topic; publish the customerpre-approval to the customer pre-approval topic; and subscribe, by oneor more processing platforms, to the customer pre-approval topic.
 9. Thesystem of claim 8, comprising: receiving, at the attribute and incomeplatform, a risk score.
 10. The system of claim 9, wherein the riskscore is based on the financial profile.
 11. The system of claim 8,wherein the customer pre-approval is further based on account stateinformation from a credit account platform.
 12. The system of claim 11,comprising: providing, by the event streaming platform, an account statetopic; streaming, by the credit account platform, the account stateinformation to the account state topic; and subscribing, by the customerdecisioning platform, to the account state topic.
 13. The system ofclaim 8, wherein the one or more processing platforms includes atransaction decisioning platform.
 14. The system of claim 10, whereinthe financial profile and the risk score are updated iteratively on atime interval, and comprising: determining an eligibility of thecustomer for the customer pre-approval iteratively on the time interval.15. A non-transitory computer readable storage medium, includinginstructions stored thereon, which instructions, when read and executedby one or more computer processors, cause the one or more computerprocessors to perform steps comprising: receiving, at an attribute andincome platform, demand deposit account information associated with ademand deposit account; receiving, at the attribute and income platform,financial information of a customer associated with the demand depositaccount; generating, by the attribute and income platform, a financialprofile for the customer; generating, by a customer decisioningplatform, a customer pre-approval of a credit product for the customer,wherein the customer pre-approval is based on the financial profile forthe customer; providing, by an event streaming platform, a customerpre-approval topic; publishing the customer pre-approval to the customerpre-approval topic; and subscribing, by one or more processingplatforms, to the customer pre-approval topic.
 16. The non-transitorycomputer readable storage medium of claim 15, comprising: receiving, atthe attribute and income platform, a risk score.
 17. The non-transitorycomputer readable storage medium of claim 16, wherein the risk score isbased on the financial profile.
 18. The non-transitory computer readablestorage medium of claim 15, wherein the customer pre-approval is furtherbased on account state information from a credit account platform. 19.The non-transitory computer readable storage medium of claim 18,comprising: providing, by the event streaming platform, an account statetopic; streaming, by the credit account platform, the account stateinformation to the account state topic; and subscribing, by the customerdecisioning platform, to the account state topic.
 20. The non-transitorycomputer readable storage medium of claim 17, wherein the financialprofile and the risk score are updated iteratively on a time interval,and comprising: determining an eligibility of the customer for thecustomer pre-approval iteratively on the time interval.